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METHOD AND SYSTEM FOR QUALITY OF SERVICE PROVISIONING FOR IP 
VIRTUAL PRIVATE NETWORKS 

Cross Reference to Related Application 

This application claims tlie benefit of U.S. Provisional Application No. 
5 60/245,597, filed November 3, 2000, the contents of which are hereby incorporated by 
reference. 

Background of the Invention 

The present invention relates generally to communications networks, and more 
particularly, to a method and system for facilitating provisioning of networks to support 
1 0 different classes of traffic. 

Packet networks, such as the Internet, are increasingly used to transport voice as 
well as data. Although using a common network infrastructure to transport both voice 
and data potentially offers significant cost advantages, network providers have not been 
able to provide a consistent quality of service (QoS) for voice communications over the 
15 Internet. 

Unlike data communications, voice communications require timely reception of 
packets at a receiver in a network to achieve an acceptable QoS. This requires 
consistent low packet delays and losses in the network. Existing Internet Protocol (IP) 
networks including the Internet, however, generally do not provide consistent low packet 

20 delays and losses because they maximize the use of network resources through a 
statistical multiplexing method, which is suitable for best effort traffic, but not for real- 
time applications, such as voice. 

The Internet Engineering Task Force (IETF) has attempted to solve this problem 
by implementing the Resource Reservation Protocol (RSVP) and Integrated Services. 

25 However, the RSVP and Integrated Services have failed to gain widespread acceptance 
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because they require networks to maintain a per-flow state in network routers. 
Currently, IETF is considering a Differentiated Services effort to provide individual 
mechanisms for enabling different classes of traffic in a network. This method, 
however, does not provide an enabling methodology for use by Internet Service 
5 Providers (ISPs) in provisioning their networks to achieve a consistent QoS when 
transporting voice over their networks. 

SUMMARY OF THE INVENTION 

To overcome the above and other disadvantages of the prior art, methods and 
systems are provided for provisioning a network to support different classes of traffic, 
1 0 characterized, for example, by their respective QoS criteria. 

Such methods and systems provision a network by identifying the classes of 
traffic to be transported in the network as well as the QoS criteria of the identified 
classes of traffic. By simulating the classes of traffic, one or more QoS mechanisms 
and their associated parameters may be determined. The statistical multiplexing gains 
15 of the classes of traffic may also be determined based on the simulation. Then, one or 
more resources in the network may be allocated based on the QoS mechanisms and 
parameters as well as the multiplexing gains. 

In one embodiment, traffic classes and their associated QoS criteria may be 
characterized by, for example, one or more of packet loss, one-way time delay, packet 
20 jitter, loss distribution, or other similar factors. 

In another embodiment, a request to establish a flow between two nodes in the 
network may be received. The request may include a desired bandwidth. A path 
between the two nodes may be identified and the available bandwidth along that path 
may be determined. If the available bandwidth along that path is sufficient to satisfy the 
25 request, the flow may be established. One or more nodes in the network through which 
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the flow is established may be configured based on the QoS mechanisms and 
parameters. 

In another embodiment, available bandwidth along a path in the network may be 
updated as follows: The path may be compared to a previous path to identify if links 
5 have been added or deleted. For every added link, the requested bandwidth may be 
subtracted from the available bandwidth on that link. For every deleted link, the 
requested bandwidth may be added to the available bandwidth for that link. Any link 
that has an available bandwidth of less than zero may then be identified as congested. 
The summary of the invention and the following description for carrying out the 
10 best mode of the invention should not restrict the scope of the claimed invention. Both 
provide examples and explanations to enable others to practice the invention. The 
accompanying drawings, which form part of the description for carrying out the best 
mode of the Invention, show several embodiments of the invention, and together with 
the description, explain the principles of the invention. 

15 BRIEF DESCRIPTION OF THE DRAWINGS 

In the Figures: 

Figure 1 illustrates an exemplary network, in accordance with methods 
and systems consistent with the present invention; 

Figure 2 is a flow chart of the steps for provisioning a network to support 
20 different traffic classes, in accordance with methods and systems consistent with the 
present invention; 

Figure 3 is an block diagram illustrating a simulator for provisioning a 
network, in accordance with methods and systems consistent with the present 
invention; and 
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Figure 4 is a flow chart of the steps for simulating traffic in a network, in 
accordance with methods and systems consistent with the present invention. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Reference will now be made in detail to the preferred embodiments of the 
5 invention, examples of which are illustrated in the accompanying drawings. Wherever 
possible, the same reference numbers will be used throughout the drawings to refer to 
the same or like parts. 

Figure 1 illustrates a network 100 and a system 150, in accordance with methods 
and systems consistent with the present invention. The network 100, which may be 

10 owned and/or operated by an Internet Service Provider (ISP), may include a plurality of 
core routers 110 and edge routers 120, which may be connected to each other via links 
1 1 5. The edge routers may also be on either the ISP's premises or the customer's 
premises. Edge routers 120 may each include one or more conditioning mechanisms, 
such as marking, shaping, and policing. A network operator may use marking 

1 5 mechanisms to configure an edge router to tag traffic to a specific traffic class. Shaping 
mechanisms may permit a network operator to configure an edge router to change the 
characteristics of traffic, such as reducing traffic rate. A network operator may use 
policing mechanisms to configure an edge router to drop traffic that violates preset 
thresholds. 

20 Core routers 110 may include QoS or minimum bandwidth assurance 

mechanisms, such as Weighted Fair Queuing (WFQ) and Deficit Round Robin (DRR). 
Core routers 110 and edge routers 120 may be interconnected by a plurality of links 
1 1 5. Customer sites 130, which may be also managed by the ISP and interface with 
edge routers 120, may communicate with each other through network 100. 
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Network 100 may interface with otiner ISP networks through one or more edge 
routers 120. In addition to core routers 110 and edge routers 120, network 100 may 
also include a number of monitor nodes 140. A monitor node 140 may gather 
information about the traffic transported through network 100, such as packet loss and 
5 one-way time delay on links 1 1 5 and provide that information to system 1 50. 

System 150 may include an input device 155, a simulator 160, and a network 
operation center (NOC) 165. Input device 155 may include a direct data entry device, 
such as a keyboard, a device for indirect data entry, such as a floppy disk drive or CD- 
ROM, or a communication device, such as a modem, for receiving data from network 

10 1 00. Data entered or received may include traffic classes and their respective source 
models, topology information about network 1 00 and one or more QoS criteria for 
applications, as selected by the ISP administrator. Applications may be running on 
customer sites 1 30. Data entered or received by input device 1 55 may be provided to 
simulator 160, which then simulates the traffic transported through network 100 based 

1 5 on the provided data. The output of simulator 1 60 may include QoS mechanisms and 
parameter values for provisioning network 100. This output may be provided to NOC 
1 65 via a floppy disk or over a data link (not shown). Simulator 1 60 may include, for 
example, a personal computer or a workstation. 

NOC 165 may include an admission controller 170, a data storage device 175, 

20 and a performance feedback component 1 80. NOC 1 65 may include, for example, a 
personal computer or a workstation. Admission controller 170 may receive requests to 
establish one or more services between a pair of edge routers 120 and determine if 
sufficient network resources exist to establish the requested services. Data storage 
device 175 may include data about the topology of network 100, the available 

25 bandwidth on each link 1 1 5 in network 1 00, a set of paths each including one or more 
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links 115, and QoS data, such as QoS mechanisms and associated parameters. 
Performance feedback component 180 may receive information from monitors 140 as 
well as data storage device 175, and may function in conjunction with admission 
controller 170 to update available bandwidth on each link 115 and the set of paths 
5 stored in data storage device 1 75. 

Figure 2 is a flow chart of the steps for provisioning the network 1 00 to support 
different IP traffic classes. First, the ISP administrator may identify the desired classes 
of traffic to be transported by network 1 00, source models for each class of traffic, and 
the respective QoS criteria for each class of traffic (step 200). A class of traffic may be 

10 characterized by one or more QoS criteria, such as a certain level of packet loss and/or 
one-way time delay that may be tolerated by the class of traffic. Other characterizations 
may include packet jitter and loss distribution. Source models may include information 
such as the packet size of the class of traffic as well as the amount of time the traffic is 
on or off. For example, in a voice-over IP application, there may be a distribution of talk 

1 5 time versus pause time, where packets are generated only during the talk time. 

After identifying the classes of traffic and associated QoS criteria, the ISP may 
identify a set of applications to support and map each application to a class of traffic 
based on the QoS criteria of the application. While each application may be mapped to 
only one traffic class, each class of traffic may support one or more applications. 

20 Exemplary applications may include voice-over IP, Web TCP, and Best Effort. For 

example, voice-over IP may require a consistently low packet loss and delay. The ISP 
administrator may provide the identified classes of traffic, source models and QoS 
criteria, along with information about the topology of network 100, to the simulator 160 
using input device 155. 
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Next, simulator 160 may simulate the classes of traffic and determine QoS 
mechanisms based on the simulation (step 210). For example, based on the bandwidth 
information on linl<s 115, the traffic source models and the QoS criteria provided by the 
ISP administrator, simulator 160 may iteratively simulate traffic flow using various 
5 permutations of available QoS mechanisms to determine one or more QoS mechanisms 
that satisfy the QoS criteria of the classes of traffic. Exemplary mechanisms may 
include Token Bucket, Random Early Discard, Weighted Fair Queuing, and Deficit 
Round Robin. 

Simulator 160 may then provide information about the iterations to facilitate the 

10 determination of QoS mechanisms for use in the core routers 110 and edge routers 
120. Once the ISP administrator, based on the results of the simulation, determines a 
set of QoS mechanisms, simulator 160 may then determine the associated parameters 
of each of the QoS mechanisms satisfying the QoS criteria of the classes of traffic (step 
220). This process may be similar to the simulation done to determine the appropriate 

15 QoS mechanisms. 

Simulator 160 may also calculate the statistical multiplexing gains of the traffic 
classes based the QoS criteria (step 230). After the ISP administrator determines the 
appropriate QoS mechanisms and their associated parameters, the administrator may 
allocate one or more resources in the network 1 00 based on the determined QoS 

20 mechanisms and associated parameters and the calculated statistical multiplexing gain 
(step 240). For example, the ISP administrator may allocate resources by provisioning 
one or more routers in the network 100. The traffic classes and QoS criteria may be 
identified and network 1 00 may be provisioned, for example, off line. 

Once network 100 is provisioned, the admission controller 170 may provide 

25 admission control for network 1 00. When a first customer site 1 30 wishes to 
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communicate with another customer site 130, the first customer site 130 may send to 
the admission controller 170 a request for a connection (step 250). The customer 
request may also include the desired bandwidth for the communication. Admission 
controller 170 may then determine if there is sufficient bandwidth available to establish 
5 the requested flow (step 260). In one embodiment, the admission controller 170 may 
include a database of information about network 100, including information about a set 
of links 1 15 for each IP path as defined by edge router 120 pairs and the provisioned 
and available bandwidth for each IP-level link 1 15 in the network 100 for each traffic 
class. Alternatively, this information may be stored in data storage device 175. 

1 0 Admission controller 1 70 may determine a path including one or more links 1 1 5 

between the two customer sites 130 and further determine the available bandwidth on 
the links 1 1 5 in the determined path. If the available bandwidth is greater than or equal 
to the requested bandwidth, admission controller 170 may accept the request. 

If admission controller 170 determines there is sufficient bandwidth available and 

1 5 the request is accepted, admission controller 170 may establish the communication flow 
between the customer sites 1 30 (step 270). Further, based on the determined QoS 
mechanisms, their associated parameters, and the determined multiplexing gain, the 
admission controller 170 may configure one or more of the nodes (including edge 
routers 120 and core routers 110) through which the flow is established. 

20 Additional admission control features and embodiments consistent with the 

present invention may also be implemented using the methods and systems described 
in K. Kim, P. Mouchtaris, S. Samtani, R. Talpade, and L. Wong, "A Simple Admission 
Control Algorithm for IP Networks", in Proceedings of International Conference on 
Networking, 2001 , which is incorporated herein in its entirety by reference. 
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Finally, performance feedback component 180 may dynamically update 
information about network 100 to provide better service, based on network information 
stored In data storage device 175 or admission controller 170 and data received from 
monitors 140 (step 280). To update the available bandwidth information, first 
5 performance feedback component may compare each path stored in data storage 
device 175 (or admission controller 170) to the current path to determine any changes, 
such as the addition or deletion of links 1 1 5. For every new or added link, performance 
feedback component 180 may subtract the requested bandwidth from the available 
bandwidth for the link. For each deleted link, performance feedback component may 

10 add the requested bandwidth to the available bandwidth for the link. Congested links 
may then be identified as those links with an available bandwidth of less than zero. In a 
network with a Multiprotocol Label Switching (MPLS) capability, alternative paths may 
be established to avoid bad and congested links. 

Figure 3 is a block diagram illustrating the step of simulating and provisioning of 

15 the network 100 (shown as step 210 in Figure 2). Input to the simulator 160 may 
include the bandwidth of the links 115, traffic source models, and the QoS criteria 
associated with each traffic class. Traffic source models may include information about 
the size of the packets in each traffic class and how frequently packets are generated. 
Simulator 160 then may simulate each class of traffic according to the traffic source 

20 model and apply to one or more core routers 110 and/or edge routers 120 different 

conditioning mechanisms, such as Token Bucket, and scheduling mechanisms, such as 
Weighted Fair Queuing and Deficit Round Robin. Simulator 160 may provide 
information about which conditioning and/or scheduling mechanisms satisfy the QoS 
criteria for each class of traffic as well as the parameters for configuring these 

25 mechanisms. An ISP administrator may then determine a set of edge and core router 
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QoS mechanisms and the associated parameters and provision the edge routers 120 
and core routers 110 based on the simulation results. 

Figure 4 is a flow chart of the steps for simulating traffic transported through 
networl< 1 00, in accordance with methods and systems consistent with the present 
5 invention. First, an ISP administrator may determine a model for network 100 (step 
400). For example, the model of network 100 may be represented by a directed graph 
consisting of a set of nodes, including core routers 110 and edge routers 120, and a set 
of links 115 connecting the nodes. Each link 115 may include an associated bandwidth 
and/or an associated latency. 

10 Next, the ISP administrator may determine a source model for each class of 

traffic transported through the network 100 (step 410). For each traffic class, the source 
model may include the size of the packets in the traffic class as well as the frequency 
with which the packets are generated. For example, a source model for voice traffic 
may reflect that a person's speech includes pause times. Therefore, the model for 

15 voice traffic may include a distribution of on periods (talking) and off periods (pause). 
Additionally, the model for voice traffic may include a packet size of, for example, 200- 
bytes. 

After the network model and the source models are determined, the ISP 
administrator may configure the simulation environment in simulator 160 (step 420). In 

20 one embodiment, an LBNL Network Simulator 2 environment (available at 

http://www.isi.edu/snam/ns/) may be used to establish the simulation environment and 
represent network 100 based on the network model and source models. The ISP 
administrator may also select one or more simulation variables for each simulation run. 
Further, the simulation variables may be varied as part of the simulation, including the 

25 number of connections for each class of traffic, the link capacities, or the buffer size. 
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Additionally, the configurations of the conditioning mechanisms may also be varied. For 
example, if the Token Bucket mechanism is included in edge routers 120, the simulation 
variables may then include the token rate or the token bucket depth. 

For each choice of simulation variables, simulator 160 may be invoked to 
5 simulate network 100 (step 430). The simulation environment in simulator 160 may be 
configured based on the network model, the source models, and the chosen simulation 
variables. The simulation may run for a desired length of time, for example, 150 
simulation seconds, may run until a number of packets have been sent, or may run until 
other criteria are met. Additionally, the simulation may run multiple times, such as three 

1 0 times, using the same simulation variables to obtain statistically significant results. 
During the simulation, simulator 160 may determine data, such as queuing delays, 
delay distribution, packet loss rates, and link utilization rates, based on which the ISP 
administrator may configure network 100. Following each run of the simulation, the 
simulation variables may be altered and the simulation may be repeated (step 440). 

15 Once the simulation runs are completed, the ISP administrator may allocate one 

or more resources in network 100 as follows: For example, consider a first simulation 
using a Token Bucket mechanism in edge routers 1 20, with a token rate of 1 .5 Mbps 
and a bucket depth of 20 packets. In a second simulation, a token rate of 1 .5 Mbps and 
a bucket depth of 100 packets may be used instead. Finally, in a third simulation, a 

20 token rate of 10.0 Mbps and a bucket depth of 133 packets may be used. The data 
determined during these three simulations may indicate that the multiplexing gain 
associated with the token rate of 10.0 Mbps is the greatest. Thus, in configuring the 
Token Bucket mechanism in network 100, a token rate parameter of 10.0 may prove 
desirable. 
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Additional provisioning and simulation features and embodiments consistent witli 
the present invention may also be implemented using the methods and systems 
described in G. Kim, P. Mouchtaris, S. Samtani, R. Talpade, and L. Wong, "QoS 
Provisioning for VoIP in Bandwidth Broker Architecture: A Simulation Approach", in 
5 Proceedings of Communication Networks and Distributed Systems iVIodeling and 
Simulation Conference, 2001; and O. Altintas, K. Kim, S. Samtani, R. Talpade, and L. 
Wong, "A Methodology for Provisioning Quality of Service in IP Networks", International 
Workshop on Quality of Service, 2001 , both of which are incorporated herein in their 
entireties by reference. 

1 0 While it has been illustrated and described what are at present considered to be 

preferred embodiments and methods of the present invention, it will be understood by 
those skilled in the art that various changes and modifications may be made, and 
equivalents may be substituted for elements thereof without departing from the true 
scope of the invention. 

1 5 In addition, many modifications may be made to adapt a particular element, 

technique, or implementation to the teachings of the present invention without departing 
from the central scope of the invention. Therefore, it is intended that this invention not 
be limited to the particular embodiments and methods disclosed herein, but that the 
invention include all embodiments falling within the scope of the appended claims. 
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